System and method for safety-critical software automated requirements-based test case generation

ABSTRACT

Automated requirements-based test case generation method includes constructing a software architecture model derived from software design model architectural information, allocating requirement models into blocks/operators of the software architecture model, and generating component-level requirements-based test cases from the software architecture configured to be executable at different levels in the software architecture. The component-level requirements-based test case generation method includes receiving a software architecture along with allocated requirement models represented in hierarchical data flow diagram, selecting one of the software components, building an intermediate test model based on the selected component by automatically attaching at least one of test objectives or constraints to the corresponding software architecture model blocks/operators based on the selected test strategy, and generating human and machine readable test cases with the test generator for further automatic conversion to test executable and test review artifacts. A system and a non-transitory computer-readable medium for implementing the method are also disclosed.

CLAIM OF PRIORITY

This patent application claims the benefit of priority as acontinuation-in-part, under 35 U.S.C. § 120, to U.S. patent applicationSer. No. 14/947,633, filed Nov. 20, 2015, titled “SYSTEM AND METHOD FORSAFETY-CRITICAL SOFTWARE AUTOMATED REQUIREMENTS-BASED TEST CASEGENERATION” (now U.S. Pat. No. TBD; issued MONTH DD, 2018), the entiredisclosure of which is incorporated herein by reference.

BACKGROUND

Safety-critical software, such as aviation software, is required bycertification standards (e.g., DO-178B/C for aviation software) to bestrictly verified against certification objectives. Testing is anessential part of the verification process. Manual test case generationfrom the requirements is hard and time-consuming, especially withcomplex, large software.

Automatically generated test cases and/or test procedures derived fromthe high-level software requirements can help reduce the cost introducedby manual test case generation and review activities. Those test casesand/or test procedures generated from the specifications can be executedon the associated low-level design implementations through a testconductor.

Conventional test tools and/or models are not able to generaterequirements-based test cases at different levels in the design model.The generated test cases produced by conventional tools cannot bedirectly executed on components at multi-levels in the design.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a system for automated requirements-based test casegeneration in accordance with embodiments;

FIG. 2 depicts a process for software testing in accordance withembodiments;

FIGS. 3A-3D depict a software architecture model automatically derivedfrom a software design in accordance with embodiments;

FIG. 4 depicts a process for component-level test case generation inaccordance with embodiments;

FIG. 5 depicts a requirement model in accordance with embodiments;

FIG. 6 depicts a requirement model with attached test objectives inaccordance with embodiments;

FIG. 7 depicts a logic condition coverage model with attached testobjectives in accordance with embodiments;

FIGS. 8A-8B depict an input masking model with attached test objectivesin accordance with embodiments;

FIG. 9 depicts a test script generation and review process in accordancewith embodiments;

FIG. 10 depicts an exemplary software architecture design and theassociated requirements traceability information in accordance withembodiments;

FIG. 11 depicts an exemplary unit level test script in accordance withembodiments; and

FIG. 12 depicts an exemplary integration level test script in accordancewith embodiments.

DESCRIPTION

In accordance with embodiments, systems and methods automatically createa software architecture model from the software design architecturealong with requirement models to automate multi-level architecturalrequirements-based test case generation based on the proposed softwarearchitecture model.

In accordance with embodiments, the software architecture model and itsrequirements allocation are constructed using a model-based development(MBD) tool with the representation of a hierarchical data flow diagram.As opposed to conventional MBD tools, which are traditionally used forlow-level design, an embodying MBD tool automatically creates thesoftware architecture model from the software design architecture andgenerates corresponding test cases for the system-level or high-levelrequirements.

Embodying systems and methods can implement component-levelrequirements-based test case generation to automatically generate testcases for components at different levels in the software architecture.

FIG. 1 depicts system 100 for automated requirements-based test casegeneration in accordance with embodiments. System 100 includes controlprocessor 110 which executes computer instructions 131 to control theoperation of the system and its components. The executable instructionscan be stored in data store 130, which also can store data accessed andgenerated by the system. Control processor 110 can be located in acomputer, or a server, and interconnected to the various components viacommunication link 120. The communication link can be an internal bus,an electronic communication network, or the like. System 100 cangenerate test cases from system and/or high level requirements 132 ofthe safety-critical software.

FIG. 2 depicts process 200 for automated software testing in accordancewith embodiments. Process 200 derives software architecture model 134from the software design model. The software architecture model isconstructed, step 205, in model-based development tool 150 environmentbased on the design model's architectural information. This softwarearchitecture model can be automatically created in accordance with someimplementations. Requirement models are allocated, step 210, intodifferent modules in the software architecture model by connecting thecorresponding monitored/controlled variables (e.g., FIG. 1: VAR1-VAR19)with the input/output ports of the component. In accordance with someembodiments, at step 205 input ports for all output variables in therequirement models can be added. By adding input ports for all outputvariables, the test case generator can generate inputs and expectedoutputs for the test cases in one run.

The component-level test case generator unit 140 can use the softwarearchitecture model with allocated requirements to generate, step 215,unit/module-level requirements-based test cases. The test case generatorunit 140 can also generate, step 220, integration-level test cases toverify if the code component or integration complies with the allocatedrequirements.

FIGS. 3A-3D depict software architecture model 300 built as ahierarchical data flow diagram based on the software design architecturein accordance with embodiments. Each component Component1, Component2,Component3, Component4 in the software design is a block/operator in thesoftware architecture model with input and output ports.Blocks/operators in the software architecture model are connected witheach other and can have multiple layers of sub-blocks/sub-operators.Requirement models REQ12, REQ13, REQ14, REQ15 are allocated into thesoftware architecture model and connected to the input and output ports.The building process is automatic, systematic and modular. Thehierarchical data flow provides good visualization and easy traceabilityfrom the requirements to the software design.

FIG. 4 depicts process 400 for component-level test case generation inaccordance with embodiments. Process 400 is based on a received, step405, automatically created software architecture model in the form of ahierarchical data flow diagram with requirement models allocated. One,or more, of the software components in the software design is selected,step 410, based on the level of test generation, and the correspondingsoftware architecture model block/operator is used for test casegeneration. An intermediate test model is built, step 415, based on theselected component by attaching the test constraints and test objectivesto the corresponding software architecture model block/operator. Thetest objectives are attached to satisfy certain coverage criteria at therequirements-level, such as requirements coverage (e.g., allrequirements are activated), logic condition coverage (e.g., logicconditions in the requirements are activated at certain level), etc. Thetest constraints are attached to the model to constrain themonitored/controlled variables range and to ensure that the generatedtest cases do not violate the requirements.

The automatic test case generation strategies (i.e., to attach the testobjectives and the constraints) can be based on the general form of arequirement. In natural structural English language, the form of arequirement can be expressed as:

-   -   <antecedent expression>implies<consequent expression>,

Where <antecedent expression> is a logic expression on monitoredvariables;

and <consequent expression> is a logic expression on controlledvariables.

FIG. 5 depicts requirement model 500 (when expressed in Simulink) inaccordance with embodiments. The requirement model includes antecedentexpression 510 and consequent expression 520. These expressions areprovided to logic block 530, which implies output signal 540 based onthe expressions' states (i.e., A==>B). In order for the requirement tohold, the output signal must be 1 or “true”. The automatic test casegenerator unit 140 receives such and, from that, generates test cases,according to one or more strategies (e.g., requirements coveragestrategy, logic condition coverage strategy, input masking strategy,data completeness analysis strategy, event strategy, list strategy,decomposition and equation strategy, equivalence class strategy,boundary value analysis strategy, robustness strategy, timing strategy,etc.). Embodiments are not so limited, and other strategies for testcase generation are within the contemplation of this disclosure.

A requirements coverage strategy includes, for each requirement,generating one test case where the requirement must be satisfied withthe antecedent expression being true. This is done by inserting testobjectives and constraints and running a test generation engine that candrive the input sequences to achieve the test objectives.

By way of example, the insertion of a test objective can be done usingtest objective and test condition blocks from a commercial designverifier block library in the selected model-based development tool(e.g., such as Simulink Design Verifier blocks available from Simulink).The test generation engine can be used to drive the inputs to achievethe test objectives. FIG. 6 depicts requirement model 600 with attachedtest objectives in accordance with embodiments. Test Objective block 610(notated with a “O” within a circle), is analyzed by the design verifierto find a combination of variable value assignments VAR21, VAR22 thatcause its antecedent expression, which is of Boolean type, be true. TestCondition block 620 (notated with a “C” within a circle), causes thedesign verifier to keep the output of the “implies” block to be true. Atrue output signal of the “implies” block is an indication that therequirement REQ27 is satisfied. The value assignments to the monitoredand controlled variables are generated automatically by the designverifier.

A logic condition coverage (LCC) strategy can be implemented to achievefunctional coverage of logic equation conditions. Each condition withina logic equation is demonstrated to have an effect on the outcome of thelogic equation by varying only that condition and holding fixed for allothers that could affect the outcome. Consider the examples in Table 1,which depicts logic condition coverage for two variables, where twoBoolean values (a and b) are the conditions for the listed Booleanoperators. Table 1 indicates whether a test case is necessary to achieveLCC coverage (✓) or not (x). When the antecedent expression has one ofthese operators, test cases are generated for each of the correspondingcombinations marked with (✓), and this is generalizable for any numberof operands.

TABLE 1 Boolean Test Case (T = True, F = False) operator TT TF FT FF aAND b ✓ ✓ ✓ x a OR b x ✓ ✓ ✓ a NAND b ✓ ✓ ✓ x a NOR b x ✓ ✓ ✓ a XOR b ✓✓ ✓ ✓ a XNOR b ✓ ✓ ✓ ✓

FIG. 7 depicts logic condition coverage model 700 with attached testobjectives in accordance with embodiments. This LCC model is based onrequirement model 600 with a pattern of additional test objective andcondition blocks 710, 720, 730. In order to generate the test cases, thetest objective blocks are attached according to the Boolean operatorsused and respective cases in Table 1. After running the test generationengine, a set of test cases is generated to satisfy logic conditioncoverage. Each generated test case is also examined in order to discoverwhich requirements it “activates” activation means that the outputsignal of Satisfiability port 740 must be 1 or “true”.

An input masking strategy can achieve masking ModifiedCondition/Decision Coverage (MC/DC). The masking MC/DC meets thedefinition of independent effect by guaranteeing the same minimum testcases at each logical operator as a unique cause, and is acceptable formeeting the MC/DC objective of safety-critical software developmentstandards (e.g., DO-178B/C). Masking refers to the concept that specificinputs to a logic construct can hide the effect of other inputs to theconstruct. For example, a false input to an AND operator masks all otherinputs, and a true input to an OR operator masks all other inputs. Themasking approach to MC/DC allows more than one input to change in anindependence pair, as long as the condition of interest is shown to bethe only condition that affects the value of the decision outcome.However, analysis of the internal logic of the decision is needed toshow that the condition of interest is the only condition causing thevalue of the decision's outcome to change.

FIGS. 8A-8B depicts input masking model strategy 800 with attached testobjectives in accordance with embodiments. Each sub-expression depictedin input masking model 800 corresponds to a signal/block path thatstarts at an input condition of the antecedent expression, involving amonitored variable VAR23, VAR24, VAR25, and ends at the signal thatrepresents the result of the monitored expression. From this model, testcases can be automatically generated, associated to requirements REQ28by automatic test case generator unit 140 and translated to an outputtest script.

The input masking test generation strategy attaches test objectivesaccording to the following steps:

For each basic proposition (input condition) of the antecedentexpression, obtain the set S of all sub-expressions which contain thisproposition, except the proposition itself. Then, for each expression inset S: (1) if the top-level operation of the sub-expression is an ORgate, substitute this expression by its negation in S; (2) create anexpression e which is the conjunction of all expressions in S and thebasic proposition of above; and (3) create a test objective which mustmake expression e true.

A data completeness analysis strategy can analyze one or more variablesthat appear in the requirement and selects test objectives to testdifferent points within the physical or functional range of theparticular variables. The selection of test objectives can be based on,for example, the variable type. In one implementation, numeric variablescould be tested on their minimum, maximum, boundaries, etc.; andenumerated and Boolean variables can be tested on all possible valuesand/or states.

An event strategy can ensure that each event can be triggered at leastonce. This strategy can also ascertain that one event is notcontinuously triggered. The generated event test cases and procedurescan trigger particular events and verify the outputs with other inputconditions remain constant.

A list strategy can analyze list variables and operators that appear inthe requirement and selects test objectives to test different propertiesof lists. For example, this strategy can determine whether listoperations take place at different positions of the lists, and ensurethat each list variable is tested at least at a minimum and a maximumlist length.

A decomposition and equation strategy can analyze functions and/orequations inside of the requirement. These functions and/or equationscan be undefined in some implementations. Test objectives can beselected by analyzing the input and/or the output parameters of thesefunctions or equations, and error prone points in the defined functionsor equations.

An equivalence class strategy, a boundary value analysis strategy, and arobustness strategy can each analyze inequalities in the requirement andselect test objectives based on the equivalence class partitions thatcan be induced by the inequalities. An equivalence class strategy canselect one or more test objective for each normal equivalence class; aboundary value analysis strategy can select one or more test objectivesat the boundaries between every two equivalence classes; and arobustness strategy can select one or more test objectives for theabnormal equivalence classes.

A timing strategy can analyze one or more timing operators in therequirement and selects test objectives to test different points in thetime span—such as, for example, a leading trigger and/or a laggingtrigger. Events can be taken into consideration so that events are notalways triggered in the time span.

With reference again to FIG. 4, after attachment of the test constraintsand test objectives process 400 continues with test case generator unit140 generating test cases 136, step 420. The test case generator unitcan perform model-checking, theorem proving, constraint solving, andreachability resolution methods on the intermediate test model togenerate the test cases so as to satisfy the test objectives and/ordetect unreachable test objectives.

The model-checking and the theorem proving methods can each utilizeformal methods tools that are respectively based on model-checking ortheorem proving techniques that check the satisfaction of the negationof the test objectives against the requirements. If not satisfied, acounterexample can be generated, which can be used to generate testcases; If satisfied, the particular test objective is unreachable.

The constraint-solving method can use constraint solvers and/oroptimization tools to solve the constraints in the test objective tofind a feasible solution as a test case. If the constraints areidentified as infeasible, the corresponding test objective isunreachable.

The reachability resolution method can model a set of requirements as ahybrid model which combines discrete transitions and dynamics (ifrequirements are stateful). The model can then be analyzed to find afeasible path from initial conditions to reach the test objective, wherethe dynamics are approximated and/or analytically solved during the pathfinding. If a feasible path is identified, it can be used to generatetest cases; if no feasible paths can reach the test objective, the testobjective is identified as unreachable.

With reference again to FIG. 4, the generated test cases are translated,step 425, into test scripts for test execution and test review artifactsfor certification. The advantage of the component-level test generationmethod is that the method is flexible to automatically generaterequirements-based test cases for components at different levels in thesoftware architecture to achieve appropriate requirements-level coveragecriteria. In accordance with embodiments, test cases can be generatedapplicable to either unit/module level testing as well as integrationlevel testing.

FIG. 9 depicts process 900 for test script generation and test artifactreview in accordance with embodiments. The intermediate format 905generated by process 900 can be readable by humans and/or machines.Process 900 operates on the component-level test cases described above.An intermediate format is generated, step 905, from the test cases. Thisintermediate format can indicate the input and expected outputinformation. The intermediate format can also indicate the requirementsto which the test case traces back, the test objective that the testcase is satisfying, and the reference that the test objective is derivedfrom. The intermediate information can be used to manually, orautomatically, conduct test reviews. Certification artifacts aregenerated, step 910, from the intermediate information. The intermediateinformation can be used to generate, step 915, executable test scriptssuitable to execute in different test environments. The test scripts canalso automatically be written back, step 920, to requirements and testmanagement tools (e.g., IBM® Rational® DOORS®).

Collectively, FIGS. 10-13 depict an illustration of an end-to-endimplementation in accordance with embodiments. FIG. 10 depicts exemplarysoftware architecture design model 1000 and the associated requirementstraceability information in accordance with embodiments. The softwarearchitecture model can be constructed (FIG. 2, step 205) as a Simulinkmodel (FIGS. 3A-3D). Each block in the software design model softwarearchitecture design is converted to a block in the software architecturemodel in Simulink with the same interface and architectural information.Each block in the software architecture model is also allocated with aset of requirements models based on the requirements traceabilityinformation of FIG. 10. For example, in FIG. 3D, four requirementsmodels (1010) are allocated to component2 based on the information inFIG. 10. Similarly, block 1020 indicates the requirements traceabilityinformation for component1; block 1030 indicates the requirementstraceability information for component3; and block 1040 indicates therequirements traceability information for component4. The softwarearchitecture model depicted in FIGS. 3A-3D is then used to generaterequirements-based test cases at different levels in the softwarearchitecture.

A user can select “component2” block (FIG. 4, step 410) to generate testcases at this unit-level and select input masking test strategy. Inaccordance with embodiments, test objectives and constraints blocks willautomatically be attached to all the requirements models inside“component2” block at step 415. After calling Simulink Design Verifierat step 420 and translating test cases at step 425, the test cases thatsatisfy all the test objectives and constraints for input masking teststrategy will be generated.

FIG. 11 depicts exemplary unit level test script 1100 in accordance withembodiments. This unit level test script is an example of generated testcases at the unit-level for “component2.” The test case is generated tobe able to execute in SCADE test environment on the “component2” blockin the design. A user can alternatively select integration-level blockthat includes component 1-4 at FIG. 4, step 410 to generateintegration-level test cases. In accordance with embodiments, testobjectives and constraints blocks are automatically attached to all therequirements models inside the integration-level block at step 415.After calling Simulink Design Verifier at step 420 and translating testcases at step 425, the test cases that satisfy all the test objectivesand constraints for input masking test strategy will be generated.

FIG. 12 depicts exemplary integration level test script 1200 inaccordance with embodiments. This test script is one example for thegenerated integration level test cases. The test case is generated to beable to execute in SCADE test environment on the integration-level blockin the design.

In accordance with embodiments, a hierarchical data flow diagram (i.e.,software architecture model along with requirement models) isautomatically created to capture requirements and design information.This hierarchical data flow diagram is used to generaterequirements-based test cases at different levels in the softwarearchitecture. In accordance with embodiments, system design informationis used to build the hierarchical data flow diagram, where requirementsmodels are allocated inside modules of the hierarchical data flowdiagram. The requirements allocations are based on therequirements-module traceability information from the designinformation. Test objectives and constraints can be attached to thesoftware architecture model according to a user-selected test strategy.Automatic test case generation is based on the hierarchical data flowdiagram to generate requirements-based test cases at different levels inthe design architecture that satisfy the test objectives andconstraints. The generated test cases can be directly executed oncomponents at multi-levels in the design.

In accordance with some embodiments, a computer program applicationstored in non-volatile memory or computer-readable medium (e.g.,register memory, processor cache, RAM, ROM, hard drive, flash memory, CDROM, magnetic media, etc.) may include code or executable instructionsthat when executed may instruct and/or cause a controller or processorto perform methods discussed herein such as for automatedrequirements-based test case generation, as described above.

The computer-readable medium may be a non-transitory computer-readablemedia including all forms and types of memory and all computer-readablemedia except for a transitory, propagating signal. In oneimplementation, the non-volatile memory or computer-readable medium maybe external memory.

Although specific hardware and methods have been described herein, notethat any number of other configurations may be provided in accordancewith embodiments of the invention. Thus, while there have been shown,described, and pointed out fundamental novel features of the invention,it will be understood that various omissions, substitutions, and changesin the form and details of the illustrated embodiments, and in theiroperation, may be made by those skilled in the art without departingfrom the spirit and scope of the invention. Substitutions of elementsfrom one embodiment to another are also fully intended and contemplated.The invention is defined solely with regard to the claims appendedhereto, and equivalents of the recitations therein.

1. A method for automated requirements-based test case generation, themethod comprising: constructing a software architecture model in a modelbased development tool, the software architecture model automaticallyderived from architectural information of a software design model;allocating requirement models into different components of a softwarearchitecture model; a test case generator unit generating componentlevel requirements-based test cases from one or more levels of thesoftware architecture model; and the generated requirements-based testcases configured to be executable at different levels in the softwarearchitecture.
 2. The method of claim 1, including allocating therequirement models by connecting corresponding monitored or controlledvariables with at least one of an input port and an output port ofrespective ones of the different modules.
 3. The method of claim 1,including the test case generator unit generating integration level testcases, and applying the integration level test cases to verify if a codemodule complies with the allocated requirements.
 4. The method of claim1, including: receiving the software architecture model in the form of ahierarchical data flow diagram derived from the software design alongwith the allocated requirement models, the hierarchical data flowdiagram including one or more blocks/operators mapping to correspondingcomponents in the software design; selecting one of the softwarecomponents from the software design for test case generation; andbuilding an intermediate test model based on the selected component byautomatically attaching at least one test objectives and testconstraints to the corresponding software architecture modelblock/operator.
 5. The method of claim 4, including selecting thesoftware component based on a level of test generation.
 6. The method ofclaim 1, including generating the test cases according to at least onestrategy selected from the list of a requirements coverage strategy, alogic condition coverage strategy, an input masking strategy, a datacompleteness analysis strategy, an event strategy, a list strategy, adecomposition and equation strategy, an equivalence class strategy, aboundary value analysis strategy, a robustness strategy, and a timingstrategy.
 7. The method of claim 4, including: generatingrequirements-based test cases by performing at least one ofmodel-checking, theorem proving, constraint solving, and reachabilityresolution methods on the intermediate test model; and translating thegenerated test cases into test scripts for test execution, and into testartifacts for review.
 8. A non-transitory computer-readable mediumhaving stored thereon instructions which when executed by a processorcause the processor to perform a method for automated requirements-basedtest case generation, the method comprising: constructing a softwarearchitecture model, the software architecture model automaticallyderived from architectural information of a software design model;allocating requirement models into different blocks/operators of asoftware architecture model; generating component levelrequirements-based test cases from one or more levels of the softwarearchitecture model; and the generated requirements-based test casesconfigured to be executable at different levels in the softwarearchitecture.
 9. The non-transitory computer-readable medium of claim 8,including instructions to cause the processor to allocate therequirement models by connecting corresponding monitored or controlledvariables with an input port or an output port of respective ones of thedifferent modules.
 10. The non-transitory computer-readable medium ofclaim 8, including instructions to cause the processor to generateintegration level test cases, and apply the integration level test casesto verify if a code module complies with the allocated requirements. 11.The non-transitory computer-readable medium of claim 8, includinginstructions to cause the processor to: receive the softwarearchitecture model in the form of a hierarchical data flow diagramderived from the software design along with the allocated requirementmodels, the hierarchical data flow diagram including one or moreblocks/operators mapping to corresponding components in the softwaredesign; select one of the software components from the software designfor test case generation; and build an intermediate test model based onthe selected component by automatically attaching at least one testobjectives and test constraints to the corresponding softwarearchitecture model block/operator.
 12. The non-transitorycomputer-readable medium of claim 10, including instructions to causethe processor to generate the test cases according to at least onestrategy selected from the list of a requirements coverage strategy, alogic condition coverage strategy, an input masking strategy, a datacompleteness analysis strategy, an event strategy, a list strategy, adecomposition and equation strategy, an equivalence class strategy, aboundary value analysis strategy, a robustness strategy, and a timingstrategy.
 13. The non-transitory computer-readable medium of claim 11,including instructions to cause the processor to: generaterequirements-based test cases by performing at least one ofmodel-checking, theorem proving, constraint solving, and reachabilityresolution methods on the intermediate test model; and translate thegenerated test cases into test scripts for test execution, and into testartifacts for review.
 14. A system for automated requirements-based testcase generation, the system comprising: a model based development toolincluding a control processor configured to execute instructions, thecontrol processor connected to a communication link; a component leveltest case generator unit to automatically generate test cases.
 15. Thesystem of claim 14, including the control processor configured toexecute instructions that cause the control processor to perform thesteps of: deriving software architecture model from software designallocating requirement models into different blocks/operators of asoftware architecture model; generating component levelrequirements-based test cases.
 16. The system of claim 15, including thecontrol processor configured to execute instructions that cause thecontrol processor to generate integration level test cases, and applythe integration level test cases to verify if a code module complieswith the software architecture model and the allocated requirementmodels.
 17. The system of claim 15, including the control processorconfigured to execute instructions that cause the control processor to:receiving the software architecture model in the form of a hierarchicaldata flow diagram derived from the software design along with theallocated requirement models, the hierarchical data flow diagramincluding one or more blocks/operators mapping to correspondingcomponents in the software design; selecting one of the softwarecomponents from the software design for test case generation; andbuilding an intermediate test model based on the selected component byautomatically attaching at least one test objectives and testconstraints to the corresponding software architecture modelblock/operator.
 18. The method of claim 6, the input masking strategyincluding masking Modified Condition/Decision Coverage (MC/DC) to allowmore than one input of an input condition to change in an independentpair.
 19. The non-transitory computer-readable medium of claim 12, theinput masking strategy including masking Modified Condition/DecisionCoverage (MC/DC) to allow more than one input of an input condition tochange in an independent pair.
 20. The system of claim 15, thegenerating component level requirements-based test cases including aninput masking strategy that allows more than one input of an inputcondition to change in an independent pair.